# Snapshot - Encryption Details

Back to Backup

### Setting a default password

Drive Snapshot lets you store a default password in the registry, which will always be used when creating or using disk images; it's stored at HKCU\software\snapshot\DefaultPassword.

Although this presents some security risk, it's very convenient compared to always re-entering the password when creating/using disk images.
Although it's stored in encrypted form , there's always the risk to disassemble Snapshot.exe and retrieve the password.

Even if you don't store your password permanently, it is remembered until you close Drive Snapshot; e.g.
for creating multiple partition Backups.

### Remember your Password

If you forget your password, there's no way to recover it; you might as well delete your backup in such a case.

### Setting the password from the command line

From the command line, you can set the password with -PW=

C:>Snapshot C: X:\Backup\c-drive.sna -PW=SuperSecret

This overrides a default password.
If you have a default password, and don't set one from the command line, the default is used.
If you have a default, but nevertheless want your image unencrypted, you have to indicate an empty password:

C:>Snapshot C: X:\Backup\c-drive.sna -PW=

### En/Decryption Speed:

A 1GHz machine is able to en- and decrypt data at a rate of ~30 MB/sec; the DOS restore is ~10MB/sec

This will slow down the overall backup and Restore speed by 10-20%

### Implementation details

The used encryption (and implementation) should be 'state of the art'.

The algorithm used is AES (Rijndael) with a block and key length of 128 bits; which will be the industry standard for the next few years.

AES is used in CBC (Cipher Block Chaining) mode, to avoid some easy attacks on images, that are possible if you have a lot of cyphertext, with large portions of it known to the attacker; which is certainly the case for GB images, with all the WindowsNT OS installed.

### Big problem - and how we think we solved it

a) Any program has to tell the user 'Wrong Password', if he mistypes it accidentally

b) If the information needed to verify the password is included in the image there must be some password verification (hash), and a potential attacker has all information in its hands to run a brute force (or dictionary) attack against a password hash

c) Even if the potential key has 128 bits, users tend to use passwords with less then 15 characters, and they look much more like 'Christmastree' or (at best) '13Christmastrees' and very seldom like '[ChRiStMaS]->[TrEeS]'; so dictionary attacks are relatively easy - and that's how Password Regain utilities work.

To prevent against brute force attacks, we make the hash generation slow: not artificially by a bad implementation, but by iterating a good implementation (the AES implementation itself) for ~0.1 seconds to generate the hash; so even if an attacker has a much faster machine than yours, he can't test millions of possible keys, but only a few hundred.

To prevent against dictionary attacks, the password is salted, using the current environment as a random number generator.

However, the salt value is stored in the image, too, readily available to the attacker to use in his dictionary attack.
So lastly, we store only 20 bits of the password hash.
This gives you (the legitimate user) a chance of 1000000:1 that wrong passwords are detected, and the attacker hopefully a lot of wrong passwords (with the right hash) to try.

If you happen to enter a wrong password with the right hash, nothing bad will happen - other then you have a disk filled with garbage ;)

Comments on this (and other implementation issues) welcome.

### What the hell is 'AES'

AES is the designated new encryption standard, replacing DES.
DES (the former standard), with a key length of 56 bits, is no longer safe against brute force attacks.

So the NIST (National Institute of Standards and Technology) founded a 1998 competition to find AES (Advanced Encryption standard) as a Crypto standard for next the decade , which was decided in 2000, and Rijndael was selected as the standard.

For us there was no reason to select anything different as the implementation is sufficiently fast for Drive Snapshot's needs.

Without claiming to have read (and understood) everything below (some of it is really advanced math), here are some interesting links regarding AES, Rijndael, and encryption in general.

Why Rijndael was choosen as AES
The Rijndael Homepage and The Theory behind of Rijndael (Hardcore Mathematics !!)
TWOFISH: another candidate for AES, by Bruce Schneier

Back to Backup

Copyright © 2001-2016 Tom Ehlert Software